Affinization of transaction types

ABSTRACT

The present invention relates to a system and method for improving the efficiency of transaction processing systems by associating each one of plurality of transaction types with a respective central processing unit.

FIELD OF THE INVENTION

The present invention relates to a system and method for improving theefficiency of transaction processing systems.

BACKGROUND OF THE INVENTION

As the demand for computing resources has increased exponentially overthe past decade, new ways have been sought to allow computing systems toprocess large amounts of data and user requests in an efficient manner.

A common way to handle a large number of simultaneous user requests on asingle computing system is to divide the requests either by software orby hardware,, into separate “tasks” or “transactions”. In a softwareenvironment, this has become known as multi-tasking, a method wherebysimultaneous user requests are placed in a queue, and executed in asequential manner by a process.

A transaction request will be understood to be a request generated by asoftware application, for some task to be performed by a computingsystem. A process will be understood to be a component (usuallysoftware) within an operating system which accepts a transaction request(hereinafter referred to as a “transaction”), queues the transaction,and then processes the transaction.

It is known to improve the efficiency with which processor caches areutilised by creating an affinity between the application processes thatexecute the business logic, and the central processing units (CPUs) thatcontain the caches.

In the prior art, a particular application process may always interactwith the same CPU. The creation of an affinity between an applicationprocess and a CPU ensures that whenever a particular application processexecutes, it always executes on the same CPU. This makes better use of aCPUs cache because, by always running a particular application processon the same CPU, there is a good chance that the CPU cache will containthe information relevant to the application process from a previous run.

On the other hand, if the application process was scheduled to a randomCPU, it is likely that the CPU cache will not contain the informationneeded by the process to run, and this information will need to beloaded in from main memory, thus degrading application performance.

A solution such as the one outlined above is disclosed in patentapplication PCT/US02/07590, entitled “Improving Transaction ProcessingPerformance by Preferentially Reusing Frequently Used Processes” filedon 14 Mar. 2002 at the US Patent and Trade Mark Office.

The shortcoming of the prior art is that each application processcontinues to receive a mix of different types of transactions from thetransaction processing system. In practice, every application processperforms not one, but a number of different types of transactions. Thetransactions that an application process performs depends largely on thetypes of transactions requested by the users of the system. As usersrequest various transactions to be performed, the transactions arerandomly sent to any of the available application processes forexecution.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a method forprocessing a transaction in a transaction processing system, comprisingthe steps of, for a plurality of transaction types, associating each oneof the plurality of transaction types with at least one centralprocessing unit, and, on receipt of a transaction request from a client,determining the transaction request type, locating the associatedcentral processing unit, and forwarding the transaction request to theassociated central processing unit.

The invention provides a method whereby similar types of transactionspreferably do use the same CPU. The method is preferably achieved byaffinitizing at least one transaction type to a CPU or set of CPUs,thereby minimizing the chance that the machine instructions of onetransaction type overwrite the machine instructions of anothertransaction type in the CPU cache.

In the present context, affinization will be understood to mean anymethodology whereby similar types of transactions are preferablyallocated to a single CPU. The affinitization process preferablyincreases CPU cache performance and therefore also increases transactionthroughput, resulting in an improved response time.

This is advantageous because different types of transactions have theirown unique business logic, and therefore their own unique sequence ofmachine instructions to execute. When, in the prior art, eachapplication process (and by implication each CPU), executes a randomselection of different types of transactions, there is a highprobability that the machine instructions of a currently executingtransaction type will overwrite the cached machine instructions ofanother transaction type that previously executed on the CPU.

When a transaction of a particular type executes on the CPU, theinstructions relevant to the aforementioned transaction type are nolonger in the cache, and these instructions need to be reloaded frommain memory.

The present invention ameliorates this problem by affinitizing atransaction type with a CPU. As similar transaction “types” are alwaysexecuted on the same CPU, the need to overwrite the CPU cache isminimised, and consequently, the time taken to execute a transaction isminimised.

Preferably, the method comprises the further step of measuring theresource usage of a particular transaction type and utilising theresource usage data to allocate the transaction type to a centralprocessing unit.

Preferably, the resource usage data includes data indicative of thenumber of transactions of a particular type that are processed relativeto other transaction types.

Preferably, the resource usage data includes data indicative of theamount of computing resources required to process a transaction.

In an embodiment of the present invention, there is provided atransaction processing system that can execute a plurality oftransaction types. In the present context, a transaction will beunderstood to mean a request from a user and/or another computing systemto perform a task. This task may include the computation of amathematical value, the manipulation of data, and/or any other taskconventionally performed by the CPU of a computing system. Theaforementioned transaction types are given as examples only, and shouldbe construed as illustrative but not limiting the present invention.

The computing system which runs the transaction processing system iscomprised at least two CPU, but may comprise a multiple number of CPUs.One method employed by the applicant to ensure that the machineinstructions of one transaction do not overwrite the machineinstructions of another transaction in the CPU cache is to assign eachtransaction type to a particular CPU.

If there is a situation in which there are more available CPUs thantransaction types, the extra CPUs can have the most CPU intensivetransaction types affinitized to them so as not to waste CPU resourcesunnecessarily. Thus the most CPU intensive transaction types is may beaffinitized to more than one CPU.

Where the computing system has more transaction types than CPUs, themost CPU intensive transaction types would be allocated at least one CPUexclusively, while the less CPU intensive transaction types share a CPU.

Preferably, at least one less intensive transaction type sharesprocessing time on a CPU with at least one another less intensivetransaction type.

In a second aspect, the present invention provides a system forprocessing a transaction in a transaction processing system, comprising,association means arranged to associate each one of a plurality oftransaction types with at least one central processing unit, andallocation means arranged, on receipt of a transaction request from aclient, to determine the transaction request type, locate the associatedcentral processing unit, and forward the transaction request to theassociated central processing unit.

In a third aspect, the present invention provides a method foraffinitizing a transaction type to a central processing unit, the methodcomprising the steps of, for each transaction type, providing resourceusage data indicative of the amount of computing resources required toprocess a transaction type, and using the resource usage data toassociate each transaction type to at least one central processing unit.

In a fourth aspect, there is provided a computer program arranged, whenloaded on a computing system, to implement the method of the firstaspect of the invention, or any dependent claim thereof.

In a fifth aspect, there is provided a computer readable mediumproviding a computer program in accordance with a fourth aspect of theinvention.

DETAILED DESCRIPTION OF THE DRAWINGS

Features of the present invention will be presented in the descriptionof an embodiment thereof, by way of example, with reference to theaccompanying drawings, in which;

FIG. 1 is a flowchart outlining the steps necessary to manage a systemin accordance with an embodiment of the invention;

FIG. 2 is a schematic diagram illustrating the operation of anembodiment of the invention;

FIG. 3 is a schematic diagram illustrating the operation of anembodiment of the invention; and

FIG. 4 is a schematic diagram illustrating the operation of anembodiment of the present invention.

DESCRIPTION OF A PREFERRED EMBODIMENT

In FIG. 1, there is shown a schematic diagram of a system in accordancewith an embodiment of the present invention, comprising 4 CPUs. Thesystem software contains a number of different transaction types. Foreach CPU, there is a corresponding application process—namely H0, AH1,AH2, and AH3. An application process is a software module arranged toreceive transaction requests from an application gateway process, act asan interface between the transaction request and the CPU. One example ofa system software application which incorporates a system architecturesuch as the one described above is EAE (Enterprise ApplicationEnvironment).

EAE is a proprietary fourth generation programming environment developedby Unisys Corporation. EAE is generally utilised to build and implementtransaction processing systems, including the business logic componentsof a transaction processing system, the user interfaces of a transactionprocessing system, and the database schema of a transaction processingsystem. It will be understood that whilst the present invention isdescribed with reference to the EAE environment, the present inventionmay be applied in any other suitable computing system.

In the example given, EAE (in accordance with the prior art) willaffinitize every application process to one available CPU for all 4available CPUs. That is, an affinity exists between an applicationprocess and a CPU.

EAE also incorporates an application gateway process which isresponsible for routing the transaction requests to the applicationprocesses for execution.

It will be understood that the system software, application processes,application gateway process, and any other software application ormodule necessary to effect an embodiment of the present invention may beexecuted on any appropriate computing hardware.

In an embodiment of the present invention, the application gatewayprocess contains a function “determineTransactionType” that receives thetransaction request and determines the transaction type by analysing therequest. The application gateway process, in one embodiment alsocontains second function “mapTransactionTypeToHost” which takes thetransaction type and determines to which application host a transactionof this type should be routed. The algorithm mapping of the transactiontype to a particular application host process preferably associates eachtransaction type with a separate CPU. Where there are more transactiontypes than CPUs (as in a later example), the application gateway processuses its knowledge about the transaction type to minimize the cachecontention. If possible, the application gateway process allocates moreCPU-intensive transactions more exclusive use of the CPU.

CPUs

The steps in processing a transaction, labelled in FIG. 1, are asfollows:

Step 1. A transaction request enters the application gateway 1 g.

Step 2. The application gateway 1 g calls the “determineTransactionType”1 g function to determine the transaction type.

Step 3. The application gateway 1 g calls the “mapTransactionTypeToHost”function to determine the most suitable application host, based on theinformation gathered with regard to the transaction type. The functionmap transaction type to host contains the algorithm that affinitizestransaction types to CPUs. There are a number of possible ways toconstruct an algorithm that affinitizes transaction types to CPUs. Forexample, a “static” affinitiziation methodology may be employed. In thestatic methodology, a transaction type is allocated to a particular CPU,and all transactions of the transaction type that enter the applicationgateway process will be directed to the allocated CPU. In other words,if, for example, a transaction type called “new-order” is affinitzed toCPU No. 1, then all requests to perform the new-order transaction whichenter the application gateway process will be routed to CPU No. 1,irrespective of any other system conditions. For an algorithm to satisfythe requirements of an embodiment of this invention, the algorithm usesinformation with regard to the transaction type to choose whichtransactions to send to which CPUs, based upon the transaction type, soas to minimize cache contention and thereby preferably improveperformance.

Step 4. The application gateway forwards the transaction to theappropriate host process for processing.

Step 5. The application host process executes the transaction on the CPUto which the host process is affinitized and returns the results to theapplication gateway.

Step 6. The application gateway returns the results of the transactionto the user 1 u.

The affinization of transaction types to CPUs is best described byreference to various examples.

A first example of an embodiment of the present invention is illustratedin FIG. 2, where there is provided a transaction processing system thatcan perform 8 different types of transactions labelled 21 a, . . . , 21h. The computing system that executes the transaction processing systemis comprised of 8 CPUs labelled 22 a, . . . , 22 h. A simple method toensure that the machine instructions of one transaction do not overwritethe machine instructions of another transaction in the CPU cache is toassign each transaction type to a particular CPU (assignation denoted byarrows 23). Thus if we label the CPUs as CPU1, CPU2, . . . , CPU8 andthe transaction types as T1, T2, . . . , T8, in the present embodiment,T1 will always ran on CPU1, T2 on CPU2, and so on respectively for eachof the 8 transaction types and CPUs.

In a second example as shown in FIG. 3, there is shown a scenario inwhich there are more available CPUs than transaction types. There are 8available CPUs labelled 32 a, . . . ; 32 h but only 6 differenttransaction types 31 a, . . . , 31 f. If the aforementioned methodologywas employed in this scenario (i.e. affinitizing each transaction typeto one CPU), 2 CPUs would remain idle. Therefore, in order to avoid CPUresource wastage, the additional 2 CPUs have the most CPU intensivetransaction types affinitized to them. Thus the most CPU intensivetransaction types are affinitized to more than one CPU.

If transaction types T3 and T6 are executed very frequently and areallocated a large proportion of CPU resources compared to the othertransaction types, the transaction type T3 could be assigned to CPU3 andCPU4 (via connector 34), and transaction type T6 could be assigned toCPU7(32 g) and CPU8(32 h). The relative “intensity” of a transactiontype may be determined in any suitable way. “Intensity” may be measuredby any suitable method or means. For example, the average amount of timerequired to process a transaction type may be kept in a table of values,and the affinitization of a transaction type to a CPU may be based onthe statistical values kept in the table. In other words, historicaldata with regard to the average time taken to process a transaction of aparticular type may be employed to determine whether a transaction isclassified as “more intensive” or “less intensive”. Any suitablemethodology may be employed to differentiate transactions of differentintensities.

A third example of an embodiment of the present invention is as shown inFIG. 4, which describes a situation where there are more transactiontypes than CPUs (which is commonly the case in many real worldtransaction processing systems). If there are 4 available CPUs (labelled42 a, . . . , 42 d) but 10 transaction types (labelled 41 a, . . . , 41j) each CPU is assigned to at least one or more transaction types. Themost CPU intensive transaction types would be allocated to at least oneCPU exclusively, while the less CPU intensive transaction types mayshare a CPU. Thus if transaction type T4 is the most frequently executedtransaction type and/or is the most CPU intensive transaction type, thistransaction type T4 would be assigned to a single exclusive CPU (44).

Similarly, if transaction types T5 and T6 are found to be moderately CPUintensive, these transaction types would be assigned to another CPU(45). The remaining 7 transaction types, which are not CPU intensive andare not executed frequently may be assigned to the remaining two CPUs(43 and 46).

Each of the preceding examples illustrate the principle underlying anembodiment of the invention. Each transaction type should be affinitizedto a CPU in such a manner as to minimize the overwriting of the machineinstructions of one transaction type with the machine instructions ofanother transaction type. In order to achieve an embodiment of thisinvention, affinitization preferably requires a system or method forload management or load balancing, since different transaction typesimpose different loads on a CPU. Even in the first example give above,each transaction type has different CPU resource requirements. Whilstthere are exactly the same number of transaction types as availableCPUs, some more intensive transaction types may require exclusive accessto more than one CPU, while other less CPU intensive transaction typescan share a CPU.

It will be understood that while the above examples illustrate a way inwhich the load could be managed or balanced, the means of managing orbalancing the load on the CPUs based upon the relative cost of thetransaction types may be achieved by any suitable method. In anEnterprise Application Environment (EAE) a proprietary softwaredevelopment environment developed by Unisys, the affinitization of atransaction type to a CPU can be achieved indirectly by means of theapplication gateway and host processes. EAE provides an application hostprocess for each available CPU in the computing system which canaffinitize each of the host processes to a CPU. Thus, a transaction typemay be indirectly affinitized to a CPU by sending transactions of agiven type to the appropriate host process. Therefore, theaffinitization process may be achieved in EAE by the use of theapplication gateway, in accordance with the following sequence ofevents:

1. A transaction request enters the application gateway.

2. The application gateway determines the transaction type.

3. The application gateway determines the most appropriate applicationhost process, based upon the transaction type (and upon a loadmanagement mechanism not described in this patent application).

4. The application gateway forwards the transaction to the appropriatehost process for processing.

5. The application host process executes the transaction on the CPU towhich the host process is affinitized and returns the results to theapplication gateway.

6. The application gateway returns the results of the transaction to theuser.

Thus, in EAE, transaction types are affinitized to CPUs indirectly bymeans of the host processes, that are themselves, in turn, affinitizedto the CPUs. That is, each transaction type would be affinitized to oneor more host processes, and each host process will be affinitized to itsown CPU.

Modifications and variations as would be apparent to a skilled addresseeare deemed to be within the scope of the present invention.

1. A method for processing a transaction in a transaction processingsystem, comprising the steps of, for a plurality of transaction types,associating each one of the plurality of transaction types with at leastone of a plurality of central processing units, and, on receipt of atransaction request from a client, determining the transaction requesttype, locating the associated central processing unit, and forwardingthe transaction request to the associated central processing unit.
 2. Amethod in accordance with claim 1, comprising the further step ofmeasuring the resource usage of a particular transaction type andutilising the resource usage data to allocate the transaction type to acentral processing unit.
 3. A method in accordance with claim 2, whereinthe resource usage data includes data indicative of the number oftransactions of a particular type are processed relative to othertransaction types.
 4. A method in accordance with claim 3, wherein theresource usage data includes data indicative of the amount of computingresources required to process a transaction.
 5. A method in accordancewith claim 4, wherein at least one less intensive transaction typeshares processing time on a CPU with at least one another less intensivetransaction type.
 6. A system for processing transactions in atransaction processing system, comprising, association means arranged toassociate each one of a plurality of transaction types with at least onecentral processing unit, and allocation means arranged, on receipt of atransaction request from a client, to determine the transaction requesttype, locate the associated central processing unit, and forward thetransaction request to the associated central processing unit.
 7. Asystem in accordance with claim 6, further comprising means to obtainresource usage date of at least one transaction type, wherein theresource usage data is employed by the allocation means to allocate thetransaction type to a central processing unit.
 8. A system in accordancewith claim 7, wherein the resource usage data includes data indicativeof the number of transactions of a particular type which are processedrelative to other transaction types.
 9. A system in accordance withclaim 8, wherein the resource usage data includes data indicative of theamount of computing resources required to process a transaction type.10. A method for affinitizing a transaction type to a central processingunit, the method comprising the steps of, for each transaction type,providing resource usage data indicative of the amount of computingresources required to process a transaction type, and using the resourceusage data to associate each transaction type to at least one centralprocessing unit.
 11. A computer program arranged, when loaded on acomputing system, to implement the method of any one of claims 1 to 5.12. A computer readable medium providing a computer program inaccordance with claim 11.